Internet Engineering Task Force (IETF) K. Chowdhury, Ed. 


Request for Comments: 6611 Radio Mobile Access, Inc. 
Category: Standards Track A. Yegin 
ISSN: 2070-1721 Samsung 

May 2012 


Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario 


Abstract 


Mobile IPv6 bootstrapping can be categorized into two primary 
scenarios: the split scenario and the integrated scenario. In the 
split scenario, the mobile node’s mobility service is authorized by a 
different service authorizer than the network access authorizer. In 
the integrated scenario, the mobile node’s mobility service is 
authorized by the same service authorizer as the network access 
service authorizer. This document defines a method for home agent 
information discovery for the integrated scenario. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc661l1. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction and Scope 


The Mobile IPv6 protocol [RFC6275] requires the mobile node to have 
the following information: 


o the Home Address (HOA), 
o the home agent address, and 


o the cryptographic materials for establishing an IPsec security 
association with the home agent. 
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The cryptographic materials need to be established prior to 
initiating the registration process. The mechanism via which the 
mobile node obtains this information is called "Mobile IPv6 
bootstrapping". In order to allow a flexible deployment model for 
Mobile IPv6é, it is desirable to define a bootstrapping mechanism for 
the mobile node to acquire these parameters dynamically. [RFC4640] 
describes the problem statement for Mobile IPv6 bootstrapping. It 
also defines the bootstrapping scenarios based on the relationship 
between the entity that authenticates and authorizes the mobile node 
for network access (i.e., the Access Service Authorizer, ASA) and the 
entity that authenticates and authorizes the mobile node for mobility 
service (i.e., the Mobility Service Authorizer, MSA). The scenario 
in which the Access Service Authorizer is not the Mobility Service 
Authorizer is called the "split" scenario. The bootstrapping 
solution for the split scenario is defined in [RFC5026]. The 
scenario in which the Access Service Authorizer is also the Mobility 
Service Authorizer is called the "integrated" scenario. This 
document defines a bootstrapping solution for the integrated 
scenario. 


[RFC5026] identifies four different components of the bootstrapping 
problem: home agent address discovery, HoA assignment, IPsec Security 
Association [RFC4301] setup, and Authentication and Authorization 
with the MSA. This document defines a mechanism for home agent 
address discovery. The other components of bootstrapping are as per 
[RFC5026]. 


In the integrated scenario, the bootstrapping of the home agent 
information can be achieved via DHCPv6. This document defines the 
MIPv6 bootstrapping procedures for the integrated scenario. It 
enables home agent assignment in the integrated scenario by utilizing 
DHCP and Authentication, Authorization, and Accounting (AAA) 


protocols. The specification utilizes DHCP and AAA options and 
attribute-value pairs (AVPs) that are defined in [RFC6610] and 
[RFC5447]. This document specifies the interworking among Mobile 


Node (MN), Network Access Server (NAS), DHCP, and AAA entities for 
the bootstrapping procedure in the integrated scenario. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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General mobility terminology can be found in [RFC3753]. The 
following additional terms, as defined in [RFC4640], are used in this 
document: 


Access Service Authorizer (ASA): A network operator that 
authenticates a mobile node and establishes the mobile node’s 
authorization to receive Internet service. 


Access Service Provider (ASP): A network operator that provides 
direct IP packet forwarding to and from the mobile node. 


Mobility Service Authorizer (MSA): A service provider that authorizes 
Mobile IPv6é service. 


Mobility Service Provider (MSP): A service provider that provides 
Mobile IPv6 service. An MSP is called a "home MSP" when MSP == MSA. 
In this document, the term MSP means a Mobility Service Provider that 
has a roaming relationship with the MSA but it is not the MSA. 


Split Scenario: A scenario where the mobility service and the network 
access service are authorized by different entities. 


Integrated Scenario: A scenario where the mobility service and the 
network access service are authorized by the same entity. 


3. Assumptions and Conformance 

The following assumptions are made in this document: 

(a) MSA == ASA. 

(b) MSA and MSP have a roaming relationship. 

(c) DHCP relay and NAS are either co-located or there is a mechanism 
to transfer received AAA information from the NAS to the DHCP 
relay. 

Note: If assignment of a home agent in the home MSP is not 
required by a deployment, co-location of the NAS and the DHCP 
relay functions or a mechanism to transfer received AAA 
information from the NAS to the DHCP relay won’t be 
necessary. In such a case, only the implementation of the 


options and procedures defined in [RFC6610] should suffice. 


(d) The NAS shall support MIPv6-specific AAA attributes as specified 
in [RFC5447]. 
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4. 


4. 


(e) The AAA server in the home domain (AAAH) used for network access 
authentication (ASA) has access to the same database as the AAAH 
used for the mobility service authentication (MSA). 


If home agent assignment is required only in the ASP by the 
deployment, a minimal implementation of this specification MAY only 
support the delivery of information from the DHCP server to the DHCP 
client through [RFC6610]. However, if home agent assignment in the 
MSP is required by the deployment, an implementation conforming to 
this specification SHALL be able to transfer the information received 
from the AAA server to the NAS, and from the NAS to the DHCP relay 
function. This can be achieved either by co-locating the NAS and the 
DHCP relay functions or via an interface between these functions. 

The details of this interface are out of the scope of this 
specification. 


Solution Overview 


1. Logical View of the Integrated Scenario 


In the integrated scenario, the mobile node utilizes the network 
access authentication process to bootstrap Mobile IPv6. It is 
assumed that the access service authorizer is mobility service aware. 
This allows for Mobile IPv6 bootstrapping at the time of access 
authentication and authorization. Also, the mechanism defined in 
this document requires the NAS to support MIP6-specific AAA 
attributes and a co-located DHCP relay agent. 


Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA 
proxy in the visited network (AAAV), and a AAA server in the home 
network (AAAH). 
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| 
ASP (/MSP) ASA/MSA (/MSP) 
$------- + | +------—- + 
| | | | | 
|AAAV ‘| ----------- | -------- |AAAH | 
| | | | 
+------- + +------- + 
| 
| | 
| | 
| | 
+----- + +-----—- + | 
+----+ | NAS/| |DHcP | | 
| MN |------ DHCP |----|Server | 
+----+ Relay 
+----- + +-----—- + | 
| 
| 
+-------- + | +-------- + 
HA | HA 
in ASP in MSP 
+-------—- + | +-------- + 


Figure 1: Integrated Scenario, Network Diagram with DHCP Server 


The user’s home network authorizes the mobile node for network access 
and mobility services. Note that usage of a home agent with the 
mobile node might be selected in the access service provider's 
network or alternatively in the mobility service provider’s network. 


The MSP may be co-located with the ASP, or the ASA/MSA, or 
independent of the two. 


The mobile node interacts with the DHCP server via the relay agent 
after the network access authentication as part of the mobile node 
configuration procedure. 


4.2. Bootstrapping Message Sequence 


In this case, the mobile node is able to acquire the home agent 
address via a DHCPv6 query. In the integrated scenario, the ASA and 
the MSA are the same; it can be safely assumed that the AAAH used for 
network access authentication (ASA) has access to the same database 
as the AAAH used for the mobility service authentication (MSA). 
Hence, the same AAAH can authorize the mobile node for network access 
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and mobility service at the same time. When the MN performs Mobile 
IPv6 registration, the AAAH ensures that the MN is accessing the 
assigned home agent for that MSP. 


Figure 2 shows the message sequence for home agent allocation in both 
scenarios —-- HA in the ASP (which is co-located with the MSP), or HA 

in an MSP that is separate from ASP and possibly from the ASA/MSA as 

well. 


aoe ees ee ASP------> | <--ASA+MSA-- 
| 
4+----+ 4+------ + 4+------- + 4+----- + 
| | | | | | | | 
| MN/ | |NAS/ | | DHCP | |AAAH | 
User DHCP Server 
relay 

4+----+ 4+------ + 4+------- + 4+----- + 

| | | | 

| 1 | i | | 

|<------------- > | <---------------------- > | 

| 2 | | | 

aH > | | | 

| | | | 

| | 3 | | 

| ca i | 

| | 4 | | 

| [sE | | 

| | | | 

| 5 | 


Figure 2: Message Sequence for Home Agent Allocation 
4.2.1. Home Agent Allocation in the MSP 


This section describes a scenario where the home agent is allocated 
in the mobile node’s MSP network (s) that is (are) not co-located with 
the ASP. In order to provide the mobile node with information about 
the assigned home agent, the AAAH conveys the assigned home agent’s 
information to the NAS via a AAA protocol, e.g., [RFC5447]. 


Figure 2 shows the message sequence for home agent allocation. In 
the scenario with HA in the MSP, the following details apply. 


Chowdhury & Yegin Standards Track [Page 7] 


RFC 6611 MIPv6 Bootstrapping Integrated Scenario May 2012 


(1) The mobile node executes the network access authentication 
procedure (e.g., IEEE 802.11i1/802.1X), and it interacts with the 
NAS. The NAS is in the ASP, and it interacts with the AAAH, 
which is in the ASA/MSA, to authenticate the mobile node. In 
the process of authorizing the mobile node, the AAAH verifies in 
the AAA profile that the mobile node is allowed to use the 
Mobile IPv6 service. The AAAH assigns a home agent in the home 
MSP, and it assigns one or more home agents in other authorized 
MSPs and returns this information to the NAS. The NAS may keep 
the received information for a configurable duration, or it may 
keep the information for as long as the MN is connected to the 
NAS. 


(2) The mobile node sends a DHCPv6 Information-request message 
[RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast 
address. In this message, the mobile node (DHCP client) SHALL 
include the following: 


* the Option Code for the Visited Home Network Information 
option [RFC6610] in the OPTION_ORO. 


* Client Home Network ID FỌDN option identifying the MSP. 
* the OPTION_CLIENTID to identify itself to the DHCP server 


(3) The relay agent intercepts the Information Request from the 
mobile node and forwards it to the DHCP server. The relay agent 
also includes the received home agent information from the AAAH 
in the Relay-Supplied Options option [RFC6610]. If a NAS 
implementation does not store the received information as long 
as the MN’s session remains in the ASP, and if the MN delays 
sending a DHCP request, the NAS/DHCP relay does not include the 
Relay-Supplied Options option in the Relay Forward message. 


(4) The DHCP server: 


* identifies the client by looking at the DHCP Unique 
Identifier (DUID) for the client in the OPTION_CLIENTID. 


* determines that the mobile node is requesting home agent 
information in the MSP by looking at the Home Network ID FQDN 
option. 


* determines that the home agent is allocated by the AAAH by 
looking at the Relay-Supplied Options option. 
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* extracts the allocated home agent information from the Relay- 
Supplied Options option and includes it in the Identified 
Home Network Information option [RFC6610] in the Reply 


Message. If the requested information is not available in 
the DHCP server, it follows the behavior described in 
[RFC6610]. 


(5) The relay agent relays the Reply Message from the DHCP server to 
the mobile node. At this point, the mobile node has the home 
agent information that it requested. 


4.2.2. Home Agent Allocation in the ASP 


This section describes a scenario where the mobile node requests home 
agent allocation in the ASP by setting the id-type field to zero in 
the Home Network Identifier Option [RFC6610] in the DHCPv6 request 
message. In this scenario, the ASP becomes the MSP for the duration 
of the network access authentication session. 


Figure 2 shows the message sequence for home agent allocation. In 
the scenario with HA in the ASP, the following details apply. 


(1) The mobile node executes the network access authentication 
procedure (e.g., IEEE 802.11i1/802.1X) and interacts with the 
NAS. The NAS is in the ASP, and it interacts with the AAAH, 
which is in the ASA/MSA, to authenticate the mobile node. In 
the process of authorizing the mobile node, the AAAH verifies in 
the AAA profile that the mobile node is allowed to use the 
Mobile IPv6 services. The AAAH assigns a home agent in the home 
MSP, and it assigns one or more home agents in other authorized 
MSPs and returns this information to the NAS. Note that the 
AAAH is not aware of the fact that the mobile node prefers a 
home agent allocation in the ASP. Therefore, the assigned home 
agent may not be used by the mobile node. This leaves the 
location of the mobility anchor point decision to the mobile 
node. 


(2) The mobile node sends a DHCPv6 Information Request message 
[RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast 
address. In this message, the mobile node (DHCP client) SHALL 
include the following: 


* the Option Code for the Home Network Identifier Option 
[RFC6610] in the OPTION_ORO. 


* the OPTION_CLIENTID to identify itself to the DHCP server. 
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(3) The relay agent (which is the NAS) intercepts the Information 
Request from the mobile node and forwards it to the DHCP server. 
The relay agent also includes the received AAA AVP from the AAAH 
in the Relay-Supplied Options option [RFC6610]. 


(4) The DHCP server identifies the client by looking at the DUID for 
the client in the OPTION_CLIENTID. The DHCP server also 
determines that the mobile node is requesting home agent 
information in the ASP by looking at the Visited Home Network 
Information option. If configured to do so, the DHCP server 
allocates a home agent from its configured list of home agents 
and includes it in the Visited Home Network Information Option 
[RFC6610] in the Reply Message. Note that in this case, the 
DHCP server does not use the received information in the Relay- 
Supplied Options option. 


(5) The relay agent relays the Reply Message from the DHCP server to 
the mobile node. At this point, the mobile node has the home 
agent information that it requested. 


4.3. Bootstrapping Message Sequence: Fallback Case 


In the fallback case, the mobile node is not able to acquire the home 
agent information via DHCPv6. The mobile node MAY perform DNS 
queries to discover the home agent address as defined in [RFC5026]. 
To perform DNS-based home agent discovery, the mobile node needs to 
know the DNS server address. The details of how the MN is configured 
with the DNS server address are outside the scope of this document. 


4.4. HOA and IKEv2 SA Bootstrapping in the Integrated Scenario 


In the integrated scenario, the HoA, IPsec Security Association 
setup, and Authentication and Authorization with the MSA are 
bootstrapped via the same mechanism as described in the bootstrapping 
solution for the split scenario [RFC5026]. 


5. Security Considerations 


The transport of the assigned home agent information via the AAA 
infrastructure (i.e., from the AAA server to the AAA client) to the 
NAS may only be integrity protected as per standard Diameter or other 
AAA protocol security mechanisms. No additional security 
considerations are imposed by the usage of this document. The 
security mechanisms provided by [RFC3588] are applicable for this 
purpose. This document does not introduce any new security issues to 
Mobile IPv6. 
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